Clarifying the concern here: if trackingDataUrl is provided, I think the tracking data should remain required and createCameraKitVideoSource should reject if it cannot be fetched. The issue is the current ordering starts playback before the sidecar is loaded. With a slow .td fetch, the hidden looping video can advance before Camera Kit receives the source, which can offset replay tracking from the video timeline. If the fetch fails, the promise rejects after playback has already started and the provider has no created source to clean up, so the video can keep playing in the background.

I would fetch the tracking data before videoInput.play() (or start the fetch earlier in parallel with video loading, but still avoid playback until the tracking data is ready). Only if the desired API contract is “best effort, fall back to live tracking” would I make the tracking data non-essential, but that seems different from this PR description.

Something like this:

const trackingData = trackingDataUrl ? await fetchTrackingData(trackingDataUrl) : undefined;
if (autoplay) await videoInput.play();
res({...});

Good catch — agreed, fixed in 5c1c0cd. The tracking data is now fetched before videoInput.play(), so the looping video can't advance before Camera Kit has the source, and a failed fetch rejects before playback starts (no orphaned playing video). Added a test asserting play() isn't called when the fetch fails. This keeps the tracking data required when trackingDataUrl is set, per the PR intent.